The rapid evolution of computer and communication technologies coupled with the robust economies of the 1980s and 1990s resulted in unprecedented growth in the information technology (“IT”) field. During this period, the need to establish a competitive advantage drove companies to faster and faster rates of change to support new product offerings and expanded services. As a result of these market pressures and time constraints, most companies elected to support new products and services by adding additional back office systems. However, due to the lack of mature integration technologies, the new systems were connected to the existing IT systems by making direct connections to the software routines already in use. The vulnerability of this design is that a change in one system produces a “ripple effect” change in every system it connects with. Over time, this incremental stacking of software systems can result in an integration ceiling. That is, at a certain point, more effort is spent on the connections than on new functionality and further expansion becomes cost prohibitive.
In the late 1990s, new integration technologies emerged that made it possible to “loosely couple” applications so that systems are no longer directly connected. Thus, changes in one system would not cause a ripple effect in any other systems. The most notable of these technologies are Message Oriented Middleware (“MOM”), Publish and Subscribe messaging, and Object Request Brokers (“ORBs”). These technologies enabled companies to re-architect their conglomeration of systems into an architecture that allows them to expand in a cost-effective manner. Technologies such as these that address the problem of integrating existing systems with new systems in an organized, efficient, and economically scaleable manner can be referred to collectively as enterprise application integration (“EAI”) technologies.
An integrated enterprise may have any number of applications which interact with other applications of the enterprise. Among other things, the interface control documents (“ICDs”) for an integrated enterprise describes all of the inter-application interactions taking place within the integrated enterprise. An interaction between first and second applications of an integrated enterprise is typically in the form of a “call” comprised of a first (or “message”) portion and a second (or “attribute”) portion. The message portion of the call describes the inter-application operation to be conducted while the attribute portion of the call is comprised of one or more data attributes, each of which describes a discrete characteristic of the data involved in the inter-application operation. A common problem in inter-application operations occurs when a system designer associates an incorrect set of data attributes with a message. For example, many messages require that an acknowledgement or other type of response be issued by the application receiving the message. Oftentimes, the original command message and the subsequent response message share a common set of data attributes. An error would occur, then, if the command and response messages are associated with different sets of data attributes.
Errors such as these can only be identified through a detailed manual examination of the ICDs for an integrated enterprise. Such a task can be quite difficult, however, particularly when a “data-rich” messaging environment is involved. In a “data-rich” messaging environment, plural data attributes are associated with a single message. For example, if fifty data attributes are associated with plural messages, for example, a first (or “send”) message and a second (or “return”) message, it should readily be appreciated that the task of examining the ICD documents (or other documentation) which describe an enterprise in order to determine that both the send and return messages include all fifty data attributes in their proper format would be both difficult and time consuming. It should be further appreciated that a tool capable of producing a matrix of data attributes and messages associated with each such data attribute would greatly assist a system designer in search of correcting such errors in the ICD documents which describe an enterprise. It is, therefore, the object of this invention to provide such a tool.